When a browser user connects to a web service with a secure connection necessary for confidential data exchange, the browser and web service use a Secure Socket Layer (SSL) connection that is typically indicated in a uniform resource locator (URL) by the prefix “https:” The SSL connection requires user authentication before the connection is established. That authentication might require direct user action: entering a username and password. In lieu of username and password, the authentication can also be satisfied by a user certificate issued earlier by the web site or another source and stored by the browser. When the web service asks for authentication, the browser supplies the user certificate so the user does not have to enter a username and password.
Certificate Authorities:
User certificates must be certified by a certificate authority that is recognized by the web service to guarantee authenticity. A user certificate is accompanied by an authority certificate that identifies the authority guaranteeing the user certificate. If the web service does not recognize the certificate authority, it will not accept the user certificate, and thereby prevent the user from connecting to the web service via SSL.
A set of standard public certificate authorities guarantees most user certificates. Because the public certificate authorities are well known and reliable, a web service can rely on their guarantees. Some organizations may, however, create their own certificate authority to guarantee user certificates that are used only within the organization. The organization's web services recognize user certificates guaranteed by their own certificate authority, but outside web services will not recognize the user certificate's authority and so will not accept the user certificates created by the organization's certificate authority.
Certificate Trust Lists:
A browser can accumulate multiple user certificates as it subscribes to different secure web services. When a user requests connection to a secure web service, the web service requests a user certificate, but the browser may not know which certificate to supply, so it must ask the user to identify the correct certificate from a list of certificates.
To help reduce the list of certificates, a web service may—when it asks for a user certificate—provide a hint that contains a certificate trust list (CTL). A CTL is a list of certificate authorities that the web service will accept. Many browsers will accept a CTL hint, examine the authority list, and return only the certificates authorized by authorities in the list.
Device Management Systems:
A device management system is used to both enroll devices such as desktop computers, notebook computers, tablets and mobile smart phones, and allow enrolled devices to access secure web services. The following description refers to mobile device management (MDM) systems since easy user authentication with strong security is particularly important for MDM systems that control the access of mobile devices such as cell phones, tablets and notebook computers to web services such as SaaS applications (Software as a Service—Dropbox® or Salesforce®, for example). However, device management systems for desktop computers and other devices to web services such as SaaS applications work in essentially the same way. Therefore, although referenced as an MDM system, the described system is not limited to use with mobile devices but works in the same manner with desktop computers and the like.
An MDM system sets up user access to an MDM service. Access occurs through a connecting application on a device, the application providing a secure connection to the MDM service. Once the connecting application is connected, it provides user access to multiple SaaS applications and other web services. The MDM system handles complete authentication and authorization for the user to access the SaaS applications or other secure web services to which authorization has been granted from that device.
Single Sign-on (SSO) Versus Zero Sign-on (ZSO):
When the user begins a session with an MDM service, he signs onto the service through a connecting application running on his device. The user provides a username and password, and then has complete access to the other authorized SaaS applications or other secure web services without further sign-on. This feature is called single sign-on (SSO): the user signs onto the MDM service only once per session. No further sign-ons are required to access other secure services through the MDM service. If the user quits the MDM service, the user will need to sign on once again with username and password to start a new session.
Zero sign-on (ZSO) goes one step further: it requires no sign-on for a secure MDM service session. The connecting application is first set up through a secure connection with the MDM service, which typically occurs at the user's request, at which time the user provides a username and password. The MDM service sets up the connecting application so that the MDM service will recognize the connecting application whenever it requests a new session with the MDM service. The MDM service grants a secure connection to the connecting application without requiring the user to enter a username and password. The user can start a new MDM service session without signing on, and has full access to the secure services offered through the MDM service without any further authentication.
ZSO Prior Art:
ZSO for a secure web service is currently implemented in several different ways. It is typically implemented with a custom connecting application created as part of an MDM system. The application includes a set of one or more software libraries designed to establish a secure connection with the MDM service. The MDM service has corresponding secure-connection libraries so that the special application and the MDM service can communicate with each other to establish a secure connection without any input from the application user.
A user installs the connecting application to a device, then uses the connecting application to connect to the MDM service and use the services provided there. The connecting application, when first connecting to the MDM service, requires the user's username and password to make a secure connection. Once the user is authenticated the first time, no further authentication is required. Whenever the user uses the connecting application to start a new session with the MDM service, the application uses API calls to establish a secure connection without requiring any user input.
Using a custom connecting application for ZSO has a significant drawback: it requires users to find the application online, install the application, and then learn to use the application on their devices. Many users do not want to use a custom application to connect to web services. They find it easier to use a standard web browser which is typically already installed on a device and very familiar to the user.
It is possible to implement something very similar to ZSO on a web browser through the use of a persistent cookie that the MDM service (or any web service) creates during an initial session. The browser stores the cookie even after the session ends and/or the browser quits. When the user initiates a new session with the service, the browser supplies the service's persistent cookie back to the service, which recognizes the cookie and starts a new session without requiring authentication from the user.
This is not a true form of ZSO because persistent cookies have an expiration date (a week or so, for example) after which the user will have to log in again before starting a session. If the user deletes the cookie, which can easily happen when performing a mass cookie deletion to fix connection problems, the user will have to log in again. Cookie connections are also not as secure as security certificate connections: there are no cookie authorities to ensure authenticity. Cookies cannot be used when higher levels of authentication are required.
A web service may implement ZSO with user certificates, issuing a user certificate and accompanying authority certificate to a browser during an initial session. The browser stores both certificates where they remain even after the session ends and/or the browser quits. When the user initiates a new session with the service, the service requests the certificate pair. The browser returns the certificate pairs, which the service recognizes. The service then starts a new session without requiring authentication from the user.
This implementation can work as long as there are not too many certificates stored in the browser, but that is not usually the case in the real world. A browser accumulates certificates, often without the browser user's knowledge, as the user connects to different web services. When the user asks the browser to connect to the MDM service, the service requests the certificates, and the browser does not know which certificate pair to provide. When this happens, the browser asks the user to identify the correct certificate, which the user may not know. Even if the user does know which certificate to identify, the request becomes, in effect, an authentication request and the session is no longer a ZSO session.